In many cases, an enterprise has some common security policies to enforce in all applications. If the polices are defined in each application scope, the policy will be redundant and hard to maintain.
In the field of computer security, general access control includes authorization, authentication, access approval, and audit. Access control involves access approval, whereby a computing system makes a decision to grant or reject an access request from an already authenticated subject, based on what the subject is authorized to access. Authentication and access control are often combined into a single operation, so that access is approved based on successful authentication, or based on an anonymous access token. Authentication methods and tokens may include passwords, biometric scans, physical keys, electronic keys and devices, hidden paths, social barriers, and monitoring by humans and automated systems.
In an access control model, the entities that can perform actions in the system are usually called subjects, and the entities representing resources to which access may need to be controlled are usually called objects. Subjects and objects may be software entities rather than human users. In some models, such as the object-capability model, a software entity can potentially act as both a subject and object. Objects can include computing system resources (referred to herein briefly as “resources”) such as executable application programs (referred to herein briefly as “applications”), file system structures such as files and directories, communication ports, volatile memory segments, etc.
Access control models used by current systems can be based upon capabilities or upon access control lists (ACLs). In a capability-based model, holding an unforgettable reference or capability to an object provides access to the object (roughly analogous to how possession of a house key grants one access to his house); access is conveyed to another party by transmitting such a capability over a secure channel. In an ACL-based model, a subject's access to an object can depend on whether its identity is on a list associated with the object (roughly analogous to how a bouncer at a private party would check one's ID to see whether his name is was the guest list); access can be conveyed by editing the list. Both capability-based and ACL-based models can include mechanisms to allow access rights to be granted to all members of a group of subjects. Such a group itself can be modeled as a subject.
Access control systems can provide the services of authorization, identification and authentication, access approval, and accountability. Authorization involves specifying the actions that a subject is permitted to perform. Identification and authentication prevents illegitimate subjects from accessing a system. Access approval involves granting access during operations, by associating users with the resources that they are allowed to access based on an authorization policy. Accountability identifies the actions that a subject performed.
Authorization can involve defining access rights for subjects. An authorization policy can specify the operations that subjects are allowed to perform within a system. Some operating systems implement authorization policies as formal sets of permissions that are variations or extensions of three basic types of access. With read access, a subject can read file contents and list directory contents. With write access, a subject can change the contents of a file or directory by adding data to an existing file structure, creating a new file structure, deleting an existing file structure, or renaming an existing file structure. With execute access, a subject can cause the system to execute (run) a program. These rights and permissions can be implemented differently in systems having different access control models. Access control models are sometimes categorized as being either discretionary or non-discretionary. Some widely recognized models include discretionary access control (DAC), mandatory access control (MAC), role-based access control (RBAC), and attribute-based access control (ABAC).
In attribute-based access control (ABAC), access is granted not necessarily based on the rights of the subject associated with a user after authentication, but based on attributes of the user himself. The user can be asked to satisfy, to an access control engine, claims about his attributes. An attribute-based access control policy specifies which claims need to be satisfied in order to grant access to an object. For example, the claim could be “older than 18.” Under such circumstances, a user that could prove this claim would be granted access. Under this model, users can be anonymous because authentication and identification are not strictly required. Means for proving claims anonymously can be achieved using anonymous credentials. Extensible Access Control Markup Language (XACML) is a standard for attribute-based access control.
Discretionary access control (DAC) involves a policy determined by the owner of an object. The owner decides which users are allowed to access the object and what privileges those users have with respect to the object. In a DAC-based system, each object in the system can have an owner. In some DAC-based systems, each object's initial owner can be the subject that caused that object to be created. The access policy for an object can be determined by that object's owner. In a DAC-based system, an owner can assign access rights and permissions for specific resources such as to other subjects.
Mandatory access control (MAC) involves allowing a user to access a resource if rules exist that allow that user to access that resource. Management of a MAC-based system can be simplified when the objects are protected using hierarchical access control, and/or through the implementation of sensitivity labels. In a system using sensitivity labels, a separate sensitivity label can be assigned to each subject and object. A subject's sensitivity label can specifies its level of trust. An object's sensitivity label can specify the level of trust required to access that object. A subject is permitted to access an object if the subject's sensitivity level is equal to or greater than the level of trust required by the object. MAC-based system can use rule-based access control. Rule-based control can involve determining whether a subject should be granted or denied access to an object by comparing the object's sensitivity label to the subject's sensitivity label.
Role-based access control (RBAC) can involve an access policy determined by a system in which an object exists. RBAC systems can be non-discretionary, in that access can be controlled at the system level (by a system administrator instead of by an object's owner. RBAC systems can control collections of permissions. A role in an RBAC system can be viewed as a set of permissions. In an RBAC system, a subject can access a resource if the subject has been assigned a role that is permitted to access that resource. Roles can be combined in a hierarchy in which higher-level roles subsume permissions owned by sub-roles.
Challenges may arise in an enterprise that involves heterogeneous authorization (or access control) environments. Such heterogeneous authorization environments may employ disparate access control models. An enterprise might, for example, involve some components that employ Oracle Platform Security Service (OPSS) as an authorization environment and other components that employ Oracle Access Manager (OAM) as an authorization environment. The access controls provided by OPSS can be application-specific; such access controls can be implemented within applications by the designers of those applications, often with a deployment in a specific type of enterprise—often one that is expected to use the RBAC model enterprise-wide—in mind. Thus, the OPSS access controls that application designers incorporate into their applications can be role-based. In contrast, the access controls provided by OAM can be enterprise-wide (generally applicable rather than specific to any particular application), and specified at application deployment time rather than at application design time. The access controls provided by OAM can be based on a DAC-based model that permits policy administration to be delegated. Implementing both types of systems in a separate and segregated manner can be wasteful of system resources and duplicative of efforts.